This is a lecture on Systems Analysis and design. It focuses on the basics of object orientation.

1. +
Object Oriented Analysis
Software Analysis and Design
Michael Heron

2. +
Introduction
 In this lecture we’re going to begin discussing how we actually
go about developing a complex program.
 And we’ll do it through the medium of object orientation.
 This is likely to be a somewhat alien way to approach a
problem for many of you.
 One of the great lies of object orientation is that it is ‘easy because it
mirrors the way people think’
 However, it is the conceptual understanding that will enable you
to build very complex programs as time goes by.
 It’s a very powerful way to build functionality.

3. +
An Object Oriented System
 A properly designed object oriented system consists of:
 One or more objects.
 These objects are defined by classes.
 Each object consists of:
 Attributes
 Behaviours
 Attributes contain information about the object.
 Data
 Behaviours are instructions for acting upon that data.

4. +
The Structure of an Object
 First, we must define what we mean by an object.
 In terms of object oriented programming.
 An object is an instance of a class.
 A class is like a blueprint telling the object what structure it has.
 A class defines:
 Attributes
 Behaviours
 The object defines
 The state of attributes.
 The values that each piece of data has.

5. +
Eh?
 Let’s look at in the abstract.
 There exists, somewhere, a blueprint for a chair.
 Blueprints for the chairs on which you are sitting.
 The blueprint defines what the chair looks like.
 It defines the structure of the chair
 It defines the relationship of the legs to the seat
 This blueprint would be the class.
 The specific chairs on which you are sitting would be objects.
 They were made (instantiated) from that blueprint.

6. +
Uh…
 The blueprint tells us how the chair is supposed to behave and
what information about that chair may be mutable.
 The colour of the chair
 The material of the chair
 The size of the chair
 The class says:
 A chair has a colour, material, and size
 The object says:
 I am blue, made of leather, and am medium sized.
 Different chairs can have the same basic structure, but different
states.
 I am pink, made of suede, and am large.

7. +
Okay!
 We’ll come back to this subject later.
 Because regardless of what people may tell you, object orientation
does not come naturally to most people.
 This however is going to be the fundamental bedrock of the systems
we analyse in the coming weeks.
 The programming languages you use throughout this course
are object oriented languages.
 Visual Basic .NET
 Java
 C#
 The objects may not be emphasized to begin with.
 But they’re coming.

8. +
Attributes
 The class defines what attributes will be present in an object.
 It has these.
 We don’t know what they are yet.
 Attributes are things that an object will have.
 Usually things that are mutable (they can change).
 Consider a human face.
 It has eyes
 It has a nose
 It has a mouth
 These are modeled in a computer program as variables.
 A class is thus a collection of variables.

9. +
Behaviours
 As well as these variables, a class contains behaviours for
acting upon those variables.
 If the class is a human face:
 Attributes: Eyes, Mouth, Nose
 Behaviours: blink, smile, sniff
 These are modeled in a computer program as functions.
 Also called methods.
 Two names for the same thing, we’ll use these interchangeably.
 Behaviours / Functions / Methods
 Different words, all for the same basic concept.

10. +
Behaviours
 Behaviours can be broken down into further parts.
 Behaviours may have variables of their own.
 Temporary variables that only exist as long as the method is
executing.
 These are known as ‘local variables’ in programming.
 They have a limited scope within which they can be accessed.
 Behaviours will usually incorporate programming structures.
 Some structures allow the programmer to choose between
courses of actions.
 Some structures allow the programmer to repeat blocks of code.
 Behaviours will incorporate flow control.

11. +
Class Diagrams
 One of the reasons why software development has such a
complex vocabulary of jargon is the need for experts to
communicate succinctly.
 This is what all formal software design techniques are about.
 In order for us to begin talking about how to discuss programs,
we need some kind of share vocabulary.
 We don’t know how to really use them yet, but let’s talk about
how we can represent a class in a modeling language.
 In this case, the language is UML
 Unified Modelling Language

12. +
Object Oriented Programs
 Object oriented programs introduce new complexities of
interaction.
 Objects have a relationship to classes.
 Objects may be composed of other objects.
 Objects define their own behaviours and attributes.
 Objects can offer several levels of indirection to other objects.
 Gaining a clear perspective on how an object oriented program
fits together is key to developing and maintaining OO code.
 Which is what our analysis and design eventually leads towards.

13. +
Object Relationships
 Objects can contain references to other objects.
 This is known as composition.
 This is a has a relationship.
 Composition relationships also imply a multiplicity (or
cardinality).
 Where there is a 0 or 1 relationship, it is known as a composition.
 Where it is more, it is an aggregation.
 Formal UML notations have more precise differentiations of
composition.
 That’s for Future Us to worry about.

14. +
Object Relationships
 An object may be a specialisation of another object.
 This is known as inheritance in object orientation.
 This is a is a relationship.
 More specialised forms of inheritance exist.
 We’ll talk about these as we go along.
 For now, we’ll just use the one kind.
 The class from which another class inherits is called the parent.
 Or Super class.
 The class that does the inheriting is called the child.
 Or sub class.

15. +
Examples
 A Car:
 Has an engine (composition)
 Has four wheels (aggregation)
 Has 2 or more doors (aggregation)
 Is a vehicle (inheritance)
 A Kitten:
 Has four legs (aggregation)
 Is an animal (inheritance)
 Has a tail (composition)
 Has the property of being as cute as the dickens (composition)

16. +
Object Oriented Programs
 The relationship between objects and classes becomes very
complex in many computer programs.
 We’ll see this before too long when we return to our case study.
 Some means of representing this complexity ‘at a glance’ is
useful.
 This is what a class diagram is used for.
 It gives the static view of a program’s architecture.
 It doesn’t change when the programming is running.
 Other techniques exist too.
 They vary in effectiveness.

17. +
Class Diagrams
 At their simplest, class diagrams are just boxes with lines
connecting them to other boxes.
 They show the relationship between classes only.

18. +
Class Diagrams
 At the next level of usefulness, class diagrams also contain
information about attributes and methods.
 Attributes in the second row
 Methods in the third
 At their best, class diagrams contain class relationships,
methods, attributes, and the visibility of each.
 They also explicitly show multiplicity.
 Class diagrams are the most fundamental unit of UML.
 And also the most useful.
 If you only ever take one diagraming notation to heart, let it be this
one.

19. +
Class Diagram with Attributes

20. +
Why Use A Class Diagram?
 There are several reasons why using a class diagram leads to
a more complete view of a project.
 It shows the relationship between classes in a way that allows you
to trace accessibility.
 It shows at a glance the amount of coupling in a project.
 It shows at a glance the amount of cohesion in a project.
 It shows at a glance the impact of change.
 These are elements that tell us ‘how good an OO design we
have’
 That’s an incredibly difficult thing to assess at the moment, which is
one of the reasons why OOP is so hard to learn.

21. +
Coupling and Cohesion
 One of the biggest problems OO developers have is ensuring a
good OO design.
 What is a good OO design, you ask?
 Certainly for people unfamiliar with how OO is best done, it’s
hard to objectively rate an object architecture.
 ‘Uh, sure – it’s ten good?’
 Two objective measures exist for this though.
 Coupling
 Cohesion
 As a rule, we are aiming for high cohesion and low coupling.

22. +
Coupling
 Coupling relates to the amount of interconnectedness of
classes.
 We want this to be as low as is reasonably possible.
 There’s a reason why we don’t just link classes up in every possible
way.
 A coupling relationship is any composition, aggregation, or
inheritance.
 We can’t get away from these, but we can limit them.
 The more connections made between objects and classes, the
harder it is to make any changes.
 Because of the knock-on effect associated.

23. +
Coupling
 If your program has high coupling, there are several
disadvantages built in:
 Changes in one object may result in unexpected side-effects
elsewhere in a program.
 Often the cause is not at all obvious.
 Classes are difficult to understand at a glance.
 They make use of so much external functionality.
 Classes are difficult to test.
 They cannot be easily extracted from their context.
 We aim for low coupling, of the right kind of coupling.
 More on that later.

24. +
Cohesion
 Cohesion is the level to which an object adheres to a single set
of responsibilities.
 We want this as high as is reasonably possible.
 In a good object oriented program, each object has one firmly
defined responsibility.
 A cat object would not be responsible for keeping track of its
owner’s employment.
 A car object would not be responsible for storing the name of the
garage where it gets services.
 Good OO design requires us to make classes that have unique,
specific responsibilities.

25. +
Cohesion
 The dangers that come from low cohesion are the same as that
of high coupling.
 They’re really just two ways of reflecting the same basic concept.
 Low cohesion is an insidious problem.
 Programs with low cohesion tend to become even less coherent
over time.
 It is a consequence of badly analysed and badly designed
programs.
 You’ll learn how to do this properly in third year.

26. +
The Tension of OO Development
 Object Oriented programs are a tension between coupling and
cohesion.
 We increase cohesion by increasing coupling.
 We reduce coupling by decreasing cohesion.
 As OO developers we have to find a happy medium between
the two.
 In some cases, simple rationalization of a design can remove
problems.
 That is a judgment call that comes from experience.
 We’ll have plenty of opportunities to do this as we go through
the module.

27. +
Impact of Change
 Both of these concepts are a way of objectively rating the
impact of change in a program.
 What makes a program easy to work with?
 Clearly written code.
 Comments (seriously)
 Changes do not have unexpected consequences.
 The latter of these three is what the impact of change defines.
 That when we change a piece of code, we know what is going to be
changed as a result of it.

28. +
Impact of Change
 One of the reasons we restrict visibility of variables and
methods is to manage the impact of change.
 If you are a Respectful Developer, you avoid making changes that
will impact on code you did not write.
 Lest terrible vengeance be visited upon you and your kith and kin
 The lower the visibility, the better.
 Changing a local variable for example only impacts the method in
which it is defined.
 Changing a class wide attribute will potentially impact on every
method in the class.

29. +
Impact of Change
 In a multi-developer environment you have to assume that if
functionality is available, it has been used.
 Someone saw your calculate_awesome() method and thought ‘hey,
that does exactly what I want’
 If it can be used, you can’t idly make structural changes.
 Refactoring is fine
 Redesign is not
 We’ll talk more about refactoring in a later lecture.
 It basically means ‘improving code so well that nobody notices’

30. +
The Class Diagram
 The best quality of class diagrams shows the impact of change
at a glance.
 Where there are lots of arrows, there be coupling issues.
 Where there are huge lists of methods and attributes in a class,
there be likely cohesion problems.
 Where there are lots of public methods and attributes, there be likely
impact of change issues.
 Doing the class diagram from the start gives us a good
opportunity to identify structural problems before we write a
single line of code.

31. +
The Class Diagram
 In multi-developer projects, the class diagram represents the
‘best understanding’ of how a program is being developed.
 It’s kind of an informal contract with your fellow developers.
 One of the benefits we get from object orientation is an ease of
development and integration.
 But only if everyone is communicating effectively.
 It is important that this diagram remain up to date with the state
of the program.
 It is a ‘living document’.
 Some tools exist for automatically generating them.
 And generating program code from class diagrams.

32. +
Conclusion
 Class diagrams are awesome.
 Seriously, you need to believe me on that.
 They give us a neat way of representing a number of issues
with our programs.
 How classes relate
 The degree of coupling
 The degree of cohesion
 The likely impact of change.
 We can tell at a glance when our systems are going off the
rails.
 Huzzah.